home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Mission 3
/
Mission 3.zip
/
Mission 3.iso
/
demovers
/
texel
/
zusatz
/
gscript
/
gscript.txt
< prev
Wrap
Text File
|
1997-11-14
|
27KB
|
965 lines
Fernsteuern von GEM-Applikationen mit
GEMScript
09.11.1997 (Release 1.0)
von
Thomas Much, Holger Weets, Manfred Lippert
Inhaltsverzeichnis
==================
1 Einleitung
2 Das Konzept im Überblick
3 GEM-Nachrichten
3.1 Initialisierung
3.1.1 GS_REQUEST
3.1.2 GS_REPLY
3.1.3 Die GS_INFO-Struktur
3.2 Abmeldung
3.2.1 GS_QUIT
3.3 Fernsteuerung
3.3.1 GS_COMMAND
3.3.2 GS_ACK
3.4 Makros
3.4.1 GS_OPENMACRO
3.4.2 GS_MACRO
3.4.3 GS_WRITE
3.4.4 GS_CLOSEMACRO
4 Nachstarten eines GS-Interpreters
5 Standard-GS-Kommandos
5.1 Close
5.2 Copy
5.3 Cut
5.4 Delete
5.5 GetFront
5.6 New
5.7 Open
5.8 Paste
5.9 Print
5.10 Quit
5.11 Save
5.12 SaveAs
5.13 SelectAll
5.14 ToFront
5.15 Undo
6 Weitere GS-Kommandos
6.1 Exec
6.2 CheckApp
7 Parameter
7.1 Leere Parameter
7.2 Datei
7.3 Datei+Pfad
7.4 Script
Anhang
======
A History
B Kontakt
1 Einleitung
*************
GEMScript ist ein Protokoll, um GEM-Applikationen fernzusteuern. Das
Protokoll selbst ist sehr einfach gehalten, so daß es für
Programmierer kein großes Problem darstellt, GEMScript in ihren
Programmen zu unterstützen.
Diese Dokumentation definiert dieses GEMScript-Protokoll und ist somit
in erster Linie an Programmierer gerichtet. Wohlgemerkt handelt es
sich bei GEMScript noch nicht um ein konkretes Programm, sondern nur
um die Definition einer Kommunikation zwischen GEM-Programmen:
Die am häufigsten auftretende Anwendung einer Kommunikation mittels
GEMScript dürfte die durch einen Script-Interpreter darstellen. Einen
solchen Interpreter stellt z.B. "Scripter" von Holger Weets dar.
Festgelegt durch ein Script in einer Sprache, die dieser Interpreter
versteht, verschickt der Interpreter über das definierte GEMScript-
Protokoll Kommandos an GEM-Programme, die dann die gewünschten
Aktionen ausführen:
Natürlich können auch GEM-Programme ohne einen Script-Interpreter
untereinander per GEMScript kommunizieren.
Die hohe Flexibilität des GEMScript-Protokolls eröffnet sich dadurch,
daß in keinster Weise die Kommandos vorgeschrieben sind, die versendet
werden. Es ist nur definiert wie Kommandos verschickt werden, nicht
aber welche Kommandos dies sind.
Jede Applikation kann also ihre eigenen Kommandos bereitstellen, je
nach dem, welche Fähigkeiten sie eben hat. Ein Zeichenprogramm wird
beispielsweise sicher andere Kommandos bereitstellen wollen, als ein
Desktop oder eine Tabellenkalkulation.
Es gibt jedoch ein paar Standard-Kommandos, die in nahezu jeder
Applikation sinnvoll erscheinen, z.B. das Öffnen eines Dokumentes.
Daher beschreibt diese GEMScript-Dokumentation ebenfalls einen Satz
solcher Standard-GS-Kommandos, an die sich jede GEMScript-fähige
Applikation - soweit möglich - halten sollte. Zwingend ist dies jedoch
nicht.
2 Das Konzept im Überblick
***************************
Wie im Vorwort schon erwähnt, handelt es sich bei GEMScript um eine
Kommunikation zwischen GEM-Programmen, bei der Kommandos verschickt
werden.
Der eigentliche Austausch basiert auf normalen AES-Nachrichten.
Das zugrundeliegende Prinzip der Kommunikation dabei ist eigentlich
recht einfach:
1. Eine Applikation, die mit einer anderen kommunizieren möchte,
meldet sich zunächst einmal bei dieser Applikation an ("Hallo!
Hier bin ich und möchte mich gerne mit dir per GEMScript
unterhalten."). Dazu gibt es die Nachrichten GS_REQUEST und
GS_REPLY.
2. Danach kann bereits die "Session" beginnen, d.h. man schickt sich
munter Kommandos zu. Dazu gibt es die Nachrichten GS_COMMAND und
GS_ACK. Die Applikationen unterhalten sich, und sagen
gegenseitig, was zu tun ist. In den meisten Fällen läuft das
ganze recht einseitig ab, d.h. eine Applikation kommandiert, was
zu tun ist (normalerweise der Script-Interpreter) und die andere
Applikation führt es aus. Natürlich sind aber auch andere
"Gespräche" denkbar.
3. Will sich eine Applikation nicht mehr unterhalten, meldet sie sich
einfach wieder ab ("Tschüß dann!"). Dazu gibt es die Nachricht
GS_QUIT.
Für Leute, denen das zu einfach ist, gibt es noch ein kleines
Schmankerl, das man in seine GEMScript-fähigen Applikationen einbauen
kann - aber nicht unbedingt muß: Die Aufnahme von Aktionen (Makros).
Eine Applikation, die das unterstützt, nennt man "aufnahmefähig".
Dazu wird nun zwingend ein Script-Interpreter gebraucht, der noch dazu
fähig sein muß, Kommandos aufzuzeichnen, um sie später wieder
abspielen zu können. Er muß quasi selbständig Scripts erstellen,
aufgrund der Informationen, die ihm eine Applikation liefert. Führt
man ein solches entstandene Script zu einem späteren Zeitpunkt aus, so
wiederholt die Applikation sinngemäß genau das, was sie bei der
Aufnahme gemacht hat.
Hier der prinzipielle Ablauf einer Aufnahme:
1. Der Benutzer aktiviert die Aufnahme in einer Applikation. Die
Applikation sucht daraufhin den GEMScript-Interpreter (startet
ihn gegebenenfalls nach) und initialisiert die GEMScript-
Kommunikation in gewohnter Weise mit GS_REQUEST/GS_REPLY. Meist
muß der Benutzer nun noch ein File auswählen, in der das
aufzunehmende Script landen soll.
2. Die Applikation gibt dem Interpreter bekannt, daß sie jetzt gerne
aufnehmen möchte. Dazu existiert die Nachricht GS_OPENMACRO. Ist
der Interpreter einverstanden, schickt er GS_MACRO zurück, als
Zeichen, daß nun die Aufnahme beginnen kann.
3. Die Applikation sendet nun alle Aktionen, die aufgenommen werden
sollen, mit der Nachricht GS_WRITE an den Interpreter. Dieser
erzeugt daraus das Script.
4. Beendet der Benutzer die Aufnahme, so sagt die Applikation dies
dem Interpreter mit der Nachricht GS_CLOSEMACRO. Fertig.
Hat man eine Applikation erst mal GEMScript-fähig gemacht, stellt im
Grunde also auch die Aufnahmefähigkeit kein großes Problem mehr dar.
Um das ganze zu vervollständigen gibt es noch eine weitere kleine
Variante der Aufnahme: Die applikationsübergreifende Aufnahme.
Dazu ist eine weitere spezielle Applikation nötig, die diese Aufnahme
koordiniert: Der Aufnahme-Server. Der Desktop "jinnee" funktioniert
beispielsweise als ein solcher Server. Auch diese
applikationsübergreifende Aufnahme sei kurz erläutert:
1. Der Benutzer aktviert die applikationsübergreifende Aufnahme im
Aufnahme-Server. Wie bei einer normalen Aufnahme, sucht dieser
Server den GEMScript-Interpreter und initialisiert die
GEMScript-Kommunikation mit GS_REQUEST/GS_REPLY.
2. Wie bei der normalen Aufnahme, beginnt der Server, eine Aufnahme
beim Interpreter zu starten (GS_OPENMACRO). Der Interpreter
antwortet mit GS_MACRO.
3. Außerdem versucht der Aufnahme-Server GEMScript-Kontakt zu allen
laufenden Applikationen aufzunehmen (GS_REQUEST/GS_REPLY). Bei
Applikationen, bei denen dies geklappt hat, löst der Server quasi
"von außen" eine Aufnahme mit der Nachricht GS_MACRO aus. Sind
die Applikationen von außen aufnahmefähig, fangen sie jetzt an,
munter ihre Kommandos per GS_WRITE an den Server zu schicken.
(Für die Applikationen ist der Server in diesem Falle der
Interpreter.)
4. Der Server sammelt alle aufzunehmenden Kommandos aller laufenden
Applikationen, kennzeichnet diese speziell (um sie später beim
Abspielen des Scripts wieder zu erkennen), und schickt diese
neuen Kommandos als "seine" aufzunehmenden Kommandos an den
Interpreter weiter. Dieser zeichnet sie im Script auf.
4. Beendet der Benutzer die Aufnahme, unterbricht der Server die
Aufnahme bei allen Applikationen ebenfalls wieder "von außen".
Ebenso beendet er seine eigene Aufnahme beim Interpreter. (Beides
mit GS_CLOSEMACRO). Fertig.
5. Spielt man das entstandene Script ab, so findet der Interpreter
nur Kommandos, die für den Server bestimmt sind, und schickt
diese dann auch an ihn. Der Server wiederum erkennt, daß es sich
um Kommandos anderer Applikationen handelt, und leitet sie
entsprechend einfach weiter. Hier sieht man den Vorteil, den der
Server hat, wenn es sich um ein Desktop handelt (wie im Falle
jinnee): Läuft eine Applikation beim Abspielen des Scripts nicht,
kann er diese meist ohne großen Aufwand einfach nachstarten,
sofern die Applikation im Desktop angemeldet ist.
Nach diesem Überblick der Möglichkeiten kann die konkrete
Dokumentation des GEMScript-Protokolls beginnen.
3 GEM-Nachrichten
******************
3.1 Initialisierung
====================
3.1.1 GS_REQUEST
-----------------
Um festzustellen, ob eine Applikation GEMScript unterstützt, schickt
man ihr folgende Message.
GS_REQUEST
msg[0] 0x1350 (4944)
msg[1] ap_id
msg[2] 0
msg[3]
+ Pointer auf GS_INFO-Struktur
msg[4]
msg[5] 0
msg[6] 0
msg[7] beliebige ID
Antwort:
Wenn die Applikation GEMScript versteht, erhält man als Antwort
GS_REPLY.
Man muß jede Applikation natürlich nur einmal vor dem ersten Kommando
auf GEMScript testen.
3.1.2 GS_REPLY
---------------
GS_REPLY wird von einer GEMScript-fähigen Applikation als Antwort auf
GS_REQUEST verschickt.
GS_REPLY
msg[0] 0x1351 (4945)
msg[1] ap_id
msg[2] 0
msg[3]
+ Pointer auf GS_INFO-Struktur
msg[4]
msg[5] 0
msg[6] 0: OK, Applikation kann GS-Kommunikation durchführen
sonst: Fehler, GS-Kommunikation derzeit nicht möglich
msg[7] ID aus GS_REQUEST
Wenn eine Applikation in msg[6] einen Fehler meldet, dürfen an sie
keine weiteren GS-Nachrichten geschickt werden. Man kann aber zu einem
späteren Zeitpunkt mit GS_REQUEST erneut die GEMScript-Fähigkeit
erfragen.
Man beachte, daß eine Applikation mehrere GS_REQUEST-Nachrichten
erhalten kann. Zum einen können verschiedene Applikationen eine
Kommunikation beginnen, aber durch die ID kann eine Applikation sogar
in mehreren "Sessions" gleichzeitig kommunizieren.
Ist eine Applikation nur auf eine laufende Kommunikation gleichzeitig
ausgelegt (z.B. weil der aktuelle Kommunikationspartner in einer
globalen Variablen vermerkt wird), so muß darauf geachtet werden, daß
alle folgenden GS_REQUEST-Nachrichten korrekt abgelehnt werden, wenn
bereits eine Kommunikation läuft. (Am besten mit einem Wert ungleich 0
in msg[6].)
3.1.3 Die GS_INFO-Struktur
---------------------------
typedef struct {
long len; /* Länge der Struktur in Bytes */
int version; /* Versionsnummer des Protokolles beim Sender
(z.Z. 0x0100 = 1.0) */
int msgs; /* Bitmap der unterstützten Nachrichten (GSM_xxx) */
long ext; /* benutzte Endung, etwa '.SIC' */
} GS_INFO;
GSM_COMMAND = 0x0001 /* kann GS_COMMAND empfangen */
GSM_MACRO = 0x0002 /* kann GS_OPENMACRO, GS_WRITE und GS_CLOSEMACRO
empfangen, GS_MACRO verschicken
(Interpreter) */
GSM_WRITE = 0x0004 /* kann GS_OPENMACRO, GS_WRITE und GS_CLOSEMACRO
verschicken, GS_MACRO empfangen
(aufnahmefähige Applikation) */
Anmerkungen zur GS_INFO-Struktur:
∙ Die Struktur muß per Mxalloc() im globalen Speicher alloziert
sein.
∙ Die Strukur darf vom Empfänger nicht verändert werden. D.h.
GS_REQUEST- und GS_REPLY-Sender müssen jeweils ihre eigene
Struktur allozieren.
∙ Da man nicht feststellen kann, wann der Empfänger die Struktur
ausgelesen hat, sollte sie grundsätzlich verfügbar sein. Es
empfiehlt sich daher, die Struktur am Anfang des Programmes zu
allozieren und erst am Ende wieder freizugeben.
∙ long belegt 32 Bit. Entspricht also auch size_t oder dem
sizeof()-Typ in Pure-C.
∙ int belegt 16 Bit.
∙ ext ist für den Interpreter gedacht. Andere Applikationen können
hier 0 eintragen.
3.2 Abmeldung
==============
3.2.1 GS_QUIT
--------------
GS_QUIT sollte an den Kommunikationspartner geschickt werden, wenn
eine fernsteuernde Applikation keine GS_COMMAND-Befehle mehr
verschickt oder wenn eine ferngesteuerte Applikation solche
Nachrichten nicht mehr auswerten kann/möchte (z.B. weil die
Applikation terminiert).
GS_QUIT
msg[0] 0x1354 (4948)
msg[1] ap_id
msg[2] 0
msg[3] 0
msg[4] 0
msg[5] 0
msg[6] 0
msg[7] ID aus GS_REQUEST
3.3 Fernsteuerung
==================
3.3.1 GS_COMMAND
-----------------
GS_COMMAND
msg[0] 0x1352 (4946)
msg[1] ap_id
msg[2] 0
msg[3]
+ Pointer auf Kommandozeile, s.u.
msg[4]
msg[5] 0
msg[6] 0
msg[7] ID aus GS_REQUEST
Die Kommandozeile enthält das eigentliche Kommando, gefolgt von
optionalen Parametern. Kommando und Parameter sind durch ASCII #0
getrennt, am Ende der Kommandozeile steht ASCII #0#0, in C-Notation
also z.B.
"Kommando\0Parameter 1\0Parameter 2\0\0"
Die Kommandos müssen beim Empfänger ohne Beachtung der Groß-/
Kleinschreibung ausgewertet werden. Dabei wäre es schön, wenn
möglichst viele Standard-GS-Kommandos unterstützt würden.
Die Zeichenkette muß per Mxalloc() im globalen Speicher alloziert
sein.
Antwort:
Als Antwort erhält man die Nachricht GS_ACK, die zum Freigeben dieses
Speichers benutzt werden kann.
Siehe auch: Parameter.
3.3.2 GS_ACK
-------------
Folgende Nachricht wird von einer GEMScript-fähigen Applikation als
Antwort auf GS_COMMAND verschickt. Die fernsteuernde Applikation kann
beim Empfang dieser Nachricht z.B. den Speicher vom msg[3/4] wieder
freigeben.
GS_ACK
msg[0] 0x1353 (4947)
msg[1] ap_id
msg[2] 0
msg[3]
+ exakt die Werte der empfangenen GS_COMMAND-Nachricht
msg[4]
msg[5]
+ Ergebnis bzw. Fehlermeldung als ASCIIZZ-Text (s.u.) oder NULL
msg[6]
msg[7] 0: (GSACK_OK) OK, Kommando wurde oder wird ausgeführt
1: (GSACK_UNKNOWN) Kommando unbekannt
2: (GSACK_ERROR) Fehler (Kommando nicht ausgeführt)
Wird in msg[5/6] eine Rückgabe geliefert, liegt diese im Format wie
die GS_COMMAND-Kommandozeile vor, also die einzelnen Werte durch ASCII
#0 getrennt mit ASCII #0#0 am Ende des Rückgabestrings.
Antwort:
Wenn die auswertende Applikation in msg[5/6] ein Ergebnis der Funktion
oder eine Fehlerbeschreibung liefert (also einen Wert ungleich NULL),
muß die fernsteuernde Applikation folgende Antwort zurückschicken. Die
auswertende Applikation kann dann ihrerseits den Ergebnisspeicher
freigeben.
GS_ACK
msg[0] 0x1353 (4947)
msg[1] ap_id
msg[2] 0
msg[3] 0
msg[4] 0
msg[5]
+ exakt die Werte der empfangenen GS_ACK-Nachricht
msg[6]
msg[7] 0
Anmerkungen zum Rückgabestring:
Der Rückgabewert eines Kommandos sollte immer über msg[5]+msg[6]
zurückgegeben werden, man sollte nicht msg[7] dafür "mißbrauchen".
Dies gilt vor allem für Kommandos, die wahr oder falsch zurückliefern.
Sofern das Kommando korrekt ausgeführt werden konnte, sollte man bei
"wahr" einen beliebigen nicht-leeren Rückgabestring (z.B. "1")
zurückliefern, bei "false" empfiehlt sich Leerstring oder Nullpointer.
Dies ist z.B. für den Interpreter "Scripter" von Holger sehr
praktisch, denn dann können True/False-Kommandos bequem durch
folgendes Script abgefragt werden:
if (kommando(...))
{
/* wahr */
}
else
{
/* falsch */
}
Würde das Ergebnis ist msg[7] zurückgeliefert, müßte man im Beispiel
"Scripter" folgendes schreiben:
kommando(...)
if (errno == 0)
{
/* wahr */
}
else
{
/* falsch */
}
3.4 Makros
===========
3.4.1 GS_OPENMACRO
-------------------
GS_OPENMACRO
(App->Interpreter)
msg[0] 0x1355 (4949)
msg[1] ap_id
msg[2] 0
msg[3]
+ Pointer auf Dateinamen, unter dem das Script gespeichert werden soll
msg[4]
msg[5] 0
msg[6] 0
msg[7] 0
Eine Applikation will vom Script-Interpreter aufgenommen werden. Als
Antwort bekommt sie GS_MACRO.
Der Interpreter sollte über die Environment-Variable GEMSCRIPT gesucht
und ggf. auch nachgestartet werden.
Die Datei-Endung für Scripte kann die Applikation vom Interpreter über
die GS_INFO-Struktur bei GS_REPLY erfahren. Diese Endung wird evtl.
für den Fileselector benötigt, den man in den meisten Fällen vor einer
Aufnahme aufrufen wird.
Zusammenfassung des Ablaufs einer Aufnahme:
∙ Interpreter suchen und ggf. nachstarten. (GEMSCRIPT-Variable)
∙ Beim Interpreter anmelden (GS_REQUEST)
∙ Interpreter anwortet mit GS_REPLY (liefert GS_INFO)
∙ Fileselector aufrufen (Extension aus GS_INFO vom Interpreter)
∙ Aufnahme mit GS_OPENMACRO starten
∙ Interpreter liefert GS_MACRO
∙ Aufnahme per GS_WRITE/GS_ACK
∙ Am Ende Aufnahme mit GS_CLOSEMACRO beenden
3.4.2 GS_MACRO
---------------
GS_MACRO
(Interpreter->App)
msg[0] 0x1356 (4950)
msg[1] ap_id
msg[2] 0
msg[3]
+ exakt die Werte der empfangenen GS_OPENMACRO-Nachricht
oder NULL bei Aufnahme-Aufforderung
msg[4]
msg[5] ID (am einfachsten das Dateihandle) zur Identifizierung des Scripts
msg[6] 0: Datei ist geöffnet, Aufzeichnung kann beginnen; sonst: Fehler
msg[7] 0
Zu beachten: GS_MACRO kann auch ohne ein vorheriges GS_OPENMACRO
auftreten. msg[3/4] ist dann NULL.
Dieser Fall soll quasi Aufforderung zur Aufnahme betrachtet werden,
wodurch z.B. eine applikationsübergreifende Aufnahme durch einen
externen Aufnahme-Server möglich ist. Die Applikation wird also
aufgefordert, ab jetzt alle Aktionen per GS_WRITE an den Aufnahme-
Server (der das GS_MACRO gesendet hat) zu schicken.
Will oder kann die Applikation gerade nicht aufnehmen, so muß sie ein
GS_CLOSEMACRO zurücksenden.
Zusammenfassung des Ablaufs einer erzwungenen Aufnahme:
∙ Aufnahmeserver (z.B. jinnee) meldet sich mit GS_REQUEST bei der
Applikation an. Applikation antwortet mit GS_REPLY.
Aufnahmeserver stellt über GS_INFO-Struktur fest, daß Applikation
GS_MACRO kann, also aufnahmefähig ist.
∙ Aufnahmeserver erzwingt Aufnahme mit GS_MACRO (NULL im
Dateinamen)
∙ Applikation antwortet entweder mit GS_CLOSEMACRO (Ablehnung) oder
nimmt einfach mit GS_WRITE/GS_ACK die Aktionen auf.
∙ Aufnahmeserver oder Applikation beendet Aufnahme mit
GS_CLOSEMACRO
3.4.3 GS_WRITE
---------------
GS_WRITE
(App->Interpreter)
msg[0] 0x1357 (4951)
msg[1] ap_id
msg[2] 0
msg[3]
+ Pointer auf Kommandozeile (wie bei GS_COMMAND)
msg[4]
msg[5] ID aus GS_MACRO
msg[6] 0
msg[7] 0
Der Interpreter antwortet auf diese Nachricht wie bei GS_COMMAND mit
GS_ACK, ohne allerdings in msg[5/6] ein Ergebnis zurückzuliefern.
Falls in diesem GS_ACK ein Fehler signalisiert wird, sollten keine
weiteren GS_WRITE-Nachrichten verschickt werden.
3.4.4 GS_CLOSEMACRO
--------------------
GS_CLOSEMACRO
(App->Interpreter / Interpreter->App)
msg[0] 0x1358 (4952)
msg[1] ap_id
msg[2] 0
msg[3] 0
msg[4] 0
msg[5] ID aus GS_MACRO
msg[6] 0
msg[7] 0
Beendet die Aufzeichnung eines Scripts.
Zu beachten: Die Aufnahme kann von beiden Seiten beendet werden.
Sowohl von der aufnehmenden Applikation selbst, als auch vom
Interpreter (Aufnahme-Server bei applikationsübergreifender Aufnahme).
4 Nachstarten eines GS-Interpreters
************************************
Damit Applikationen (z.B. zum Aufzeichnen von Makros) einen GS-
Interpreter per appl_find() finden oder - falls ein solcher nicht
läuft - nachstarten können, kann im Environment die Variable GEMSCRIPT
gesetzt werden, beispielsweise
#_ENV GEMSCRIPT=D:\SCRIPTER\SCRIPTER.APP
5 Standard-GS-Kommandos
************************
5.1 Close
==========
Kommando: Close
Parameter: Datei (optional)
Rückgabe: keine
Schließt das der Datei entsprechende Fenster. Wenn keine Datei
übergeben wurde, wird das oberste Fenster geschlossen. Das Kommando
darf auch so implementiert sein, daß mehrere Datei-Parameter auf
einmal übergeben werden können.
5.2 Copy
=========
Kommando: Copy
Parameter: Datei (optional)
Rückgabe: keine
Kopiert die Selektion der angegebenen Datei auf das Klemmbrett. Wenn
keine Datei angegeben ist, wird die Selektion des obersten Fensters
verwendet.
5.3 Cut
========
Kommando: Cut
Parameter: Datei (optional)
Rückgabe: keine
Schneidet die Selektion der angegebenen Datei aus und schreibt sie auf
das Klemmbrett. Wenn keine Datei angegeben ist, wird die Selektion des
obersten Fensters verwendet.
5.4 Delete
===========
Kommando: Delete
Parameter: Datei (optional)
Rückgabe: keine
Schneidet die Selektion der angegebenen Datei aus. Wenn keine Datei
angegeben ist, wird die Selektion des obersten Fensters verwendet.
5.5 GetFront
=============
Kommando: GetFront
Parameter: keine
Rückgabe: Datei oder Datei+Pfad
Falls das oberste Fenster der Applikation einen Namen besitzt, mit dem
es in den GS-Kommandos identifiziert werden kann, sollte dieser als
Antwort auf dieses Kommando zurückgeliefert werden.
5.6 New
========
Kommando: New
Parameter: keine
Rückgabe: keine
Legt ein neues Dokument an.
5.7 Open
=========
Kommando: Open
Parameter: Datei+Pfad (optional)
Rückgabe: keine
Öffnet die angegebene Datei. Wenn keine Datei übergeben wurde, sollte
dem Benutzer die Dateiauswahlbox o.ä. angezeigt werden. Das Kommando
darf auch so implementiert sein, daß mehrere Datei-Parameter auf
einmal übergeben werden können.
5.8 Paste
==========
Kommando: Paste
Parameter: Datei (optional)
Rückgabe: keine
Fügt den Inhalt des Klemmbretts in die Selektion der angebenenen Datei
ein. Wenn keine Datei angegeben ist, wird die Selektion des obersten
Fensters verwendet.
5.9 Print
==========
Kommando: Print
Parameter: Datei (optional)
Rückgabe: keine
Druckt die angegebene Datei aus. Wenn keine Datei angegeben ist, wird
das oberste Fenster ausgedruckt. Das Kommando darf auch so
implementiert sein, daß mehrere Datei-Parameter auf einmal übergeben
werden können.
5.10 Quit
==========
Kommando: Quit
Parameter: keine
Rückgabe: keine
Beendet die Applikation.
5.11 Save
==========
Kommando: Save
Parameter: Datei (optional)
Rückgabe: keine
Speichert die angegebene Datei. Wenn keine Datei übergeben wurde, wird
das oberste Fenster gespeichert. Das Kommando darf auch so
implementiert sein, daß mehrere Datei-Parameter auf einmal übergeben
werden können.
5.12 SaveAs
============
Kommando: SaveAs
Parameter: Datei, Datei (optional)
Rückgabe: keine
Dieses Kommando hat mindestens einen, maximal zwei Parameter. Der
erste bezeichnet den neuen Dateinamen, der zweite das zu speichernde
Fenster. Wenn der zweite Parameter nicht angegeben ist, wird das
oberste Fenster unter dem Dateinamen des ersten Parameters
gespeichert.
5.13 SelectAll
===============
Kommando: SelectAll
Parameter: Datei (optional)
Rückgabe: keine
Markiert die gesamte angegebene Datei. Wenn keine Datei angegeben ist,
wird das Dokument im obersten Fenster selektiert.
5.14 ToFront
=============
Kommando: ToFront
Parameter: Datei
Rückgabe: keine
Bringt das Fenster mit der angegebenen Datei nach vorne.
5.15 Undo
==========
Kommando: Undo
Parameter: Datei (optional)
Rückgabe: keine
Macht die letzte Aktion in der angegebenen Datei rückgängig. Wenn
keine Datei angegeben ist, wird die letzte Aktion im obersten Fenster
rückgängig gemacht.
6 Weitere GS-Kommandos
***********************
Im folgenden sind alle Kommandos aufgelistet, bei denen zwar eine
Standardisierung Sinn macht, die aber nicht zwingend unterstützt
werden müssen, oder nur von bestimmten Programmen zu unterstützen
sind.
6.1 Exec
=========
Kommando: Exec
Parameter: <Script> <Parameter>
Rückgabe: keine
Dieses Kommando muß von jedem GEMScript-Interpreter unterstützt
werden. Es dient dazu, Script-Dateien auszuführen.
Mit <Script> wird die Script-Datei angegeben, dabei muß der
Interpreter mindestens eine komplette Pfadangabe samt Extension
verstehen.
<Parameter> (optional) steht für weitere beliebige Parameter, die an
das Script weitergegeben werden, falls dies der Interpreter erlaubt.
6.2 CheckApp
=============
Kommando: CheckApp
Parameter: Datei
Rückgabe: keine
Versucht, die angegebene Datei nachzustarten.
7 Parameter
************
7.1 Leere Parameter
====================
Mehrere Parameter sind durch ASCII #0 getrennt, und das Ende der
Kommandozeile ist mit ASCII #0#0 gekennzeichnet (siehe GS_COMMAND).
Deshalb mußte für den Sonderfall "leerer Parameter" eine Ausnahme
eingeführt werden:
Leere Parameter werden durch das ASCII-Zeichen #1 gekennzeichnet, z.B.
"Kommando\0Gleich folgt ein leerer Parameter\0\1\0Gemerkt?\0\0"
Wichtig: Außerdem sind Parameter, die mit den ASCII-Zeichen #2 bis
einschließlich #6 anfangen, für zukünftige Zwecke reserviert, und
müssen vom Empfänger derzeit ignoriert werden!
Beispiel:
"Kommando\0Parameter 1\0\2Dieser Text wird ignoriert\0Parameter 2\0\0"
7.2 Datei
==========
Der Datei-Parameter bezeichnet einen Dateinamen (mit oder ohne
Pfadangabe). Da einzelne Kommandos durch ASCII #0 getrennt werden,
erfolgt kein (!) Quoting.
GEMScript-fähige Applikationen stellen i.d.R. mit einem solchen
Parameter fest, welches Fenster von einem Kommando betroffen ist. Wenn
ein direkter Vergleich von Kommando-Dateinamen und dem Fenster
zugewiesenen Dateinamen keinen Erfolg bringt, sollte die Applikation
nach einer möglichst großen Übereinstimmung von Teilstrings suchen.
7.3 Datei+Pfad
===============
Dieser Parameter bezeichnet einen Dateinamen mit absoluter Pfadangabe.
7.4 Script
===========
Dieser Parameter bezeichnet eine Script-Datei (für das Exec-Kommando).
Es handelt sich um eine Datei-Angabe, wobei die Endung der konkreten
Script-Datei auch weggelassen werden kann. Falls dia absolute
Pfadangabe fehlt, muß er Interpreter in der Lage sein, die Datei zu
finden (z.B. weil sie im Verzeichnis des Interpreters liegt).
A History
**********
Rev 1.0 (14.11.97)
∙ erste öffentliche Version
B Kontakt
**********
Thomas Much, Gerwigstraße 46, D-76131 Karlsruhe, Germany
Fax: +49 / (0)721 / 62 28 21
EMail: Thomas Much @ KA2 (MausNet)
Thomas_Much@ka2.maus.de
Thomas.Much@stud.uni-karlsruhe.de (Internet)
Holger Weets, Tangastraße 45, D-26121 Oldenburg, Germany
EMail: Holger Weets @ OL (MausNet)
Holger_Weets@ol.maus.de (Internet)
Manfred Lippert, Nordring 102, D-90409 Nürnberg, Germany
EMail: Manfred Lippert @ N (MausNet)
Manfred_Lippert@n.maus.de
ft195@fen.baynet.de (Internet)